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(54) Control and distribution protocol for a portable router framework 



(57) A control and distribution protocol (CDP) is im- 
plemented for transport across a backplane bus, 
through a high-speed serial link or through a switching 
fabric connection . The protocol includes an intra-system 
transport of dynamic routing protocol (DRP) IP messag- 
es, the distribution of routing infomnation within the rout- 
er, the transport of control and maintenance messages, 
and the transport of IP and multi-protocol label switching 
(MPLS) traffic between ingress and egress ports. The 
protocol further includes a dynamic routing and control 



driver which interacts with dynamic routing control ap- 
plications to exchange messages that are to be trans- 
mitted to packet flow processors and to handoff mes- 
sages received from packet flow processors. A packet 
flow processor driver which services messages carried 
between the dynamic routing control and packet flow 
processors. An IP traffic Interface provides transfer of 
IP L3/L2 protocol data unit (PDU) header primitive from 
the packet flow processors. Both the DRC driver and 
PFP driver include a framework transport interface. 
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Description 

TECHNICAL FIELD OF THE INVENTION 

[0001] The present invention relates to a control and distribution protocol (CDP), and more particularly to a protocol 
for providing internet protocol routing functions to a host systenn such as, for example, a telecommunication switching 
or transmission system. 

BACKGROUND OF THE INVENTION 

[0002] When building internet protocol (IP) router capabilities with centralized dynamic route detennlnatlon and dis- 
tributed high performance IP packet processing capability, that are portable to many different host system architectures, 
It Is necessary to have an efficient internal protocol for the transportation of control, maintenance, perfonmance infor- 
mation, dynamic routing protocol message distribution messages, and routing table distribution management messag- 
es. Existing implementations of IP routers are system specific, and do not lend themselves to being portable to multiple 
operating environments. 

[0003] A need exists for a protocol for use with existing and new communication system architectures to provide 
high performance internal communications capability for adding IP network routing functions to a host system such as, 
7or example, an IP router, a telecommunication switching system, or a telecommunication transmission system. Such 
a protocol assumes the addition of an IP network route processing functioning component and multiple distributed IP 
packet flow processing functional components. 

SUMMARY OF THE INVENTION 

[0004] The present invention provides for a control and distribution protocol (CDP) which is implemented for transport 
across a backplane bus, through a high-speed serial link or through a switching fabric connection. The protocol includes 
an intra-system transport of dynamic routing protocol (DRP) IP messages, the distribution of routing Infonmation within 
the router, the transport of control and maintenance messages, and the transport of IP and multi -protocol label switching 
(MPLS) traffic between ingress and egress ports. The protocol further includes a dynamic routing and control driver 
which Interacts with dynamic routing control applications to exchange messages that are to be transmitted to packet 
flow processors and to handoff messages received from packet flow processors. A packet flow processor driver is 
provided which services messages carried between the dynamic routing control and packet flow processors. An IP 
traffic interface provides transfer of IP L3/L2 protocol data unit (PDU) header primitive from the packet flow processors. 
Both the DRC driver and PFP driver include a framework transport interface. 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0005] For a more complete understanding of the present Invention and for further advantages thereof, reference is 
now made to the following Description of the Prefen-ed Embodiments taken in conjunction with the accompanying 
Drawings in which: 

FIG. 1 Is a block diagram of the present Control and Distribution Protocol; 

FIG. 2 is a block diagram of the present Dynamic Routing and Control Driver illustrating driver functions; 
FIG. 3 Is a block diagram of the present Packet Flow Processor Driver illustrating driver functions; 
FIG. 4 is a block diagram illustrating data link layer state transactions; 

FIG. 5 Is a diagram Illustrating link layer messages between the Dynamic Routing and Control Driver and Packet 
Flow Processor Driver; 

FIG. 6 is a table illustrating intra-system routing; and 
FIG. 7 is a block diagram illustrating message paths. 

DESCRIPTION OF THE PREFERRED EMBODIMENTS 

[0006] The present Control and Distribution Protocol (CDP) is an element of a Portable/Router Framework (PR F), 
and is a lightweight, connection oriented, datagram protocol that supports communications among multiple Portable 
Router Framework components. The CDP meets perfomiance requirements of small to large router implementations 
and provides flexibility and expandability for new services and functions. The present protocol is lightweight enough 
so as not to degrade performance under very demanding service requirements, yet be robust enough to provide a high 
level of reliability. 
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[0007] The present Portable Router Framework (PRF) identifies several areas of functionality that communicate with 
each other to perform their functions. The CDP facilitates this communication and defines specific messages and 
procedures relative to layer 3 and layer 2 functionality. It is assumed that lower layer physical interconnection capabil- 
ities and formatting will be defined by the target, or host, system design. Therefore, the CDP is defined such that a 

5 number of different system architectures can use the protocol with minimal changes. CDP can be implemented for 
transport across a backplane bus, through a high-speed serial link or through a switching fabric connection. The two 
primary communfcation points are the Dynamic Routing and Control (DRC) and the Packet Flow Processors (PFP). 
CDP is primarily concerned with communications within the PRF, but CDP relies on host system maintenance, admin- 
istrative and configuration capabilities to perfonn its work. 

10 [0008] FIG. 1 illustrates the major components of CDP, generally identified by the numeral 20 and the main inter- 
connections of CDP 20 with other functionality within a Portable Router Framework, generally identified by the numeral 

• 22. The CDP 20 provides services for four major router functions: (1) the intra-system transport of Dynamic Routing 
Protocol Internet Protocol (DRP IP) messages, (2) the distribution of routing infomiation within the router, (3) the trans- 
port of control and maintenance messages, and (4) the transport of IP and Multi Protocol Label Switching (MPLS) 
15 traffic between ingress and egress ports via a System Transport Media, generally Identified by the numeral 24. CDP 
Drivers 26 and 28 are either associated with the Dynamic Routing & Control (DRC) element main processor 30 or the 
Packet Flow Processor (PFP) elements 32. DRC elements 30 Include, for example, routing software of a main proc- 
essor. PFP elements 32 Include, for example, telecommunication line cards, or Interfaces to ethernet, and any data 
communication link for carrying IP traffic. In most systems there will be one online DRC driver 26. Depending on the 
20 system requirements, there may be a second DRP driver 26 utilized as a standby element that would assume control 
in the case the online unit experiences a failure. Other host systems may utilize multiple DRCs in a multiple virtual 
router arrangement. In all cases, an administrative process or other process specifies the relationship between DRCs 
and associated PFPs 32. There may be less PFPs 32 associated with each DRC 28 depending on the size and the 
partitioning of the host system. In all cases the PFPs 32 will communicate back to only one DRC driver 26. For For- 
25 warded IP and MPLS traffic, each PFP 32 is required to communicate to alt other associated PFPs 32. 

[0009] The CDP (DRC) Driver 26 provides message transport services for applications executed by the DRC driver 
26. CDP 20 is utilized by the DRC driver 26 to communicate with ail of Its associated PFPs 32. The Driver 26 has two 
main functions. The first is to interact with the DRC applications to exchange messages that need to be transmitted to 
PFPs 32 and to handoff messages received from PFPs 32. The second is to translate message format and routinig 
30 information between the CDP protocol and the host system's transport media 24 protocol which in most cases is pro- 
prietary to the host systems architecture. 

[0010] The CDP/DRC driver 26 upon initialization and receiving configuration (including system topology) infomnation 
from the host system's administrative function establishes a link layer connection with all of its associated PFP 32 
elements. To accomplish this connection, the driver 26 maintains an Inter-system routing table that specifies link ad- 

35 dresses of all active PFPs 32 and runs a CDP proprietary link layer protocol that drives the CDP link state machine. 
Link state status information is maintained for each DRC to PFP association. This link layer connection provides reliable 
transport services for messaging between the CDR/DRC Application Programming Interface (API) and the CDP/PFP 
APIs. Below the CDP link layer is an interface to the host systems transport protocols and transport media 24. This 
interface 34,36 provides a portion of the required Portable Router Framework Host System Porting Specification. 

40 [001 1] Above the CDP Link Layer are the CDP message APIs. The APIs can work in either a push or a poli-and-pull 
mode for message transfer requests depending of the host systems needs. This mode is a configurable item. When 
a message is ready for transport, the CDP interrogates the information received from the application to detennine how 
the message will be routed and if multicast is requested. Each API to the DRC code is assigned a message type 
indicator that is carried across the link in each datagram. The receiving side uses the message type indicator to deliver 

45 the message to the designated application. Each message may be addressed to a port, a PFP application or an IP 
jaddress. The CDP translates these addresses to detemnine the host system address of the associated PFP. The CDP 
then formats the message and places It in the appropriate link layer queue for a specific PFP. 
[001 2] The CDP/DRC API is composed of three APIs 40, 42, and 44 to support the three types of messaging provided 
by the CDP. The three message types are Control and Network Management messages, routing table management 

• messages, and IP formatted messages. 
[001 3] Control and Network Management API 40 allows the DRC control function to perfonm the following functions; 

• Initialization 

• Configuration 

55 • System Status monitoring 

• Synchronization 

• Fault reporting and recovery 

• Perfomnance Monitoring and reporting 
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[0014] API 40 primitive contains the following information. 
[001 5] Send messages to a PFP or a PFP group 

• Destination PFP ID or PFP Group ID 
5 • Message Type 

• Function or Action Opcode 

• Arguments 

[001 6] Receive C&M message from PFP 

10 

• Source PFP ID 

• C/M Indicator 

• Event 

• Arguments 

15 

[0017] The Routing Table Application API 42 allows the DRC to Initialize and maintain routing table infonmation held 
in all PFPs 32. API 42 also provides for the monitoring and verification of the distributed routing table contents. Table 
status and fault events received from the PFPs are signaled up to the DRC routing distribution application. The R-API 
42 primitive contains the following information. 
20 [0018] Send routing table initialization and route update 

• Transaction ID i 

• PFP ID or PFP Group ID 

• Partition ID 

25 • Infomaation Pointer 

• Infomnation Size 

• Information Check-sum 

[0019] Receive PFP Routing Table Event 

30 

• Destination DRC application ID 

• Source PFP ID 

• Event 

• Arguments. 

35 

[0020] As shown in FIG. 2, DRP software sends and receives IP fonnatted messages through ail external circuits 
that connect to other peer routers to gain knowledge of network topology. IP API 44 allows for the transport of these 
IP messages to and from the external interface circuits that are associated with PFPs that service IP networic traffic. 
The DRC applications use a Logical Interface (L!) as a local representation of the actual physical port (and virtual 

40 connection (VC)) that may be associated with a remote router interface, it is the function of the CDP/DRC IP API 44 
to prepare any IP message residing in any LI for transport to its associated outgoing router physical interface. This 
activity can be started by having the DRC software alert the CDP and push the message to the CDR/DRC IP API 44 
or by having the CDP/DRC IP-API poll for any active LI and pull the message from the U. The DRC and CDR will 
support both scenarios with the actual implementation dependent on the host system operating system capabilities. 

45 The CDP/DRC IP API 44 maintains association relationships for virtual connections assigned to ports and for ports 
assigned to PFPs. These associations can be used for multicast functions or for maintenance functions. The DP/DRC 
Li.APi also maintains an association of the outgoing ports (wA/C) with their assigned IP address that is used as the 
Source Address within the outgoing IP packet. 
[0021] The CDP/DRC IP API 44 primitive infomnation is as follows. 

so [0022] Send IP message (DRC message push or CDP message pull) 

• LIJD; Logical Interface Identification 

• IP message locator 

55 • Message ID 

• Index 

[0023] Receive IP Message from PFP 
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• Source PFP 

• Source PHY A^C 

• IP Packet or Packet pointer 

[0024] The CDP/PFP Driver 28 receives and transnnits datagram messagesf rom and to a host systems DRC function. 
Upon initialization and configuration the CDP/PFP Driver 28 establishes an link layer connection with its designated 
DRC. Following connection establishment the driver signals through its APIs that message services are available. The 
CDP/PFP Driver 28 has a one-to-one relationship with the designated DRC and provides services for the three types 
of messages carried between the DRC and the PFP The CDP/PFP Driver has an additional requirement of facilitating 
transport through a traffic interface 50 of forwarded IP traffic from an ingress PFP (port) to an egress PFP (next-hop 
port) through the host systems transport media 24 as Illustrated in FIG. 3, 

[00251 The PFP Application API contains three message type APIs that correspond to the CDP/DRC APIs and in- 
terface to associated application functions in the PFP. 

[0026] The Control and Management API 52 allows the control function in the DRC and PFP to communicate. API 
52 interacts with the control element ot the PFP 32 to deliver commands from the DRC. API 52 also accepts events 
generated within the PFP that need to be transported to the DRC for processing. The CDP/PFP C&f^-API 52 primitive 
contains the following information. 
[0027] PFP to DRC messages. 

• DRC Source ID 

• C/M Indicator t 

• Event # 

• Arguments 

[0028] DRC to PFP messages. 

• Source PRC ID 

• C/M Indicator 

• Function Operator" 

• Arguments 

[0029] The Routing Table API 54 allows communication IP routing information from the DRC to the PFP for use In 
routing IP datagram traffic. Routing Table Initialization and update messages are communicated from the DRC. Table 
status messages and perfomiance messages are communicated back the DRC. The CDP/PFP R-API 54 primitive 
infomnation is as follows. 
[0030] DRC to PFP messages 

• DRC Source ID 

• Message Type 

• Function Operator 

• Arguments 

[0031] PFP to DRC messages. 

• DRC Destination ID 

• Event* . 

• Arguments 

[0032] The IP messaging API 56 provides a path for locally addressed IP messages to reach the DRC applications. 
API 56 also provides for locally generated IP messages to be fowarded through I/O (Connections) ports assigned to 
a specific PFP. The CDP/PFP IP-API 56 primitive infomnation is as follows. 
[0033] PFP to DRC (router ingress) IP messages. 

• Destination DRC ID 

• IP Packet Locator (pointer) 

• Source Connection /Port ID (PHY-VC) 

[0034] DRC to PFP (router egress) IP messages. 
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Source DRC ID 

• ^ Message Type 

• Next-Hop (PHY-VC) 

• L3/L2 Primitive information 

• IP IVIessage Locator (pointer) 

• QQ# (Quality of Services Queuing Priority) 

[0035] Referring to FIG. 3, the CDP IP Traffic Interface 50 provides for an efficient transfer of the IP L3/L2 PDU 
Header primitive from the PFP forwarding function to the CDP for the purpose of reconstruction of the modified IP 
packet header with the IP packet data. IF Traffic Interface 50 also provides for receiving forwarded L3/I-2 PDUs from 
the Framework Transport Interface 36 and directing them to buffer memory 60 for output queuing. At this point a 
'message pointer^ is sent to the Quality of Service Queuing (QQ) 62 management function. The L3A2 PDU is stored 
in buffer 64 supported by the host system. 

[00361 Both the CDP/DRC Driver 26 and the CDP/PFP Driver 28 contain a similar functional block Framework Trans- 
port l/F 34 and 36. The Framework Transport Interface 34 and 36 perfomi several functions which are divided into two 
categories, Framework CDP functions and host system functions. For the Framework functions, the interface contains 
the CDP Link Layer protocol and perfomns a multiplexing/demultiplexing function for interacting with the CDP APIs. 
There is an Intra-system address translation function to assist In intra-system routing of CDP datagrams. The host 
system functional group is system specific and is responsible for message integration, including fonnatting, addressing 
and protocol execution, with the host systems transport media. Between the two functional groups is the CDP Interface 
that supports the Portable Router Framework portability. 

[0037] The Framework Transport Interface 34 and 36 after initialization and configuration, establish a link layer con- 
nection between the system provisioned DRC and each provisioned PFP 32. With the links established the CDP APIs 
are notified that the link is available for message transport. The FT l/F 34 and 36 use the Message type indicator carried 
within the message header to deliver datagrams to the appropriate CDP API. 

[0038] The CDP Link Layer protocol is responsible for establishing a communication link between the DRC and Its 
associated PFP modules. VVhen the Link Layer connection is established the CDP APIs are signaled that message 
services are available to the application layer functions. 

[0039] The DRC is considered to be the controlling, or master element. During the initialization phase both the DRC 
side and the PFP side of the link start timers. On the expiration of the timers, the protocol driver will issue either a 
command from the DRC or an event from the PFP to alert the other end that the a host system layer 1 connection has 
been made and therefor CDP can begin its establishment phase. If the messages are unsuccessful, the timers are 
restarted. This process will continue until the host system connection Is set. The host system is responsible for estab- 
lishing a system transport media connection to support CDP communications. Once the initial messages are received, 
The DRC side will ask the PFP for topology infomnation. When this is received from the PFP side the DRC side will 
download configuration information. The PFP will stay in a configuration state until it is told to move to a link established 
state in coordination with other PFPs. While in the configuration state the PFP side will run a timer and on expiration 
of the timer will send a 'configuration state timer expired evenf . In the link established state, CDP will accept application 
layer datagrams events or commands, for transport across the link. Also during the link established state the DRC 
side will issue 'Keep-alive* commands which will be acknowledged by the PFP side. Along with the 'Keep-^e ACK' 
event from the PFP side will be PFP element status infomnation which will include routing table status infomiaEn which 
may identify the last update ID and current table check-sum. The DRC side can command the PFP side to reset In 
which case the PFP CDP link layer will stop sen/Ice and move through the Out-Of-Service state and attempt to rees- 
tablish a connection or the DRC side can leave the PFP in an Out-of-Service condition. 

[0040] FIG 4 shows the CDP/PFP link layer state machine transitions. The timers associated with each state are 
set to default values on Initialization but can be modified dynamically by the CDP/DRC Link Topology Information 
Update command messages, 

[0041] The CDP Link Layer message set is utilized to establish communications between the DRC and a PFP and 

is shown in FIG. 5. 

[0042] CDP/DRC Link Commands 

• Who is present? (Topology Query) 

• System Topology Infomnation Initialization 

• System Topology Infomnation Update 

• Establish 

• Keep-alive 

• Reset 
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[00431 CDP/PFP Link Events 

• State-Up 

• Topology Query Response 
5 • Timer (Tn) Expired 

• Keep-alive ACK 

• Reset ACK 

[0044] In order for the Framework Transport 1/F 34 and 36 to accomplish their function, integration with the host 
10 system requires a definition of interworking procedures and exchange of configuration and addressing infomnation. 
CDP requires the capability to establish communications with all associated system elements and therefor needs to 

• maintain a table of addresses of each element that makes up the router function. This infomnation needs to be supplied 
by the host system. The CDP design defines a specific interface for integration with the host system's message transport 
implementation. It is the responsibility of the host system to implement their side of the interface. 
15 [00451 In o*'^®'' establish communications between Portable Router Framework elements, CDP 20 defines the 
address model that is required. As part of the host system porting development, the host systems administrative and 
maintenance Is required to Interact with CDP to establish and maintain Intra-system routing Information. This routing 
requires a common understanding of naming and addressing of key router elements. In this regard the DRC and PFPs 
routing function are defined. Also, the host system's router ports and associated virtual connections are defined. For 
20 portability, the host System Fabrfc Interface Address (SFIA) which identifies the host systems address for the Frame- 
work element is used as the integration key. To facilitate CDP integration, the following associations are established: 
Address Model; 

DRC{n) = SFIA 

DRC(n) Application = SFIA + Message Type 
25 PFP(n) = SFIA 

PFP{n) Partition = SFIA + Partition Number 

PFP(n) Application = SFIA + Message Type 

PHY(n) = SFIA + Card Port number 

(PHY system level = Cabinet + Shelf + Slot + Port#) 
30 Next Hop = PHY(n) + VC 

DRC_U (from PFP) = DRC(n) + PHY(n) + VP# 

DRC_LI (from DRC) = IP Address 

DRC_L1 (from C&M to CDP) = DRC(n) + PriY(n) + VP# The message stmctures for carrying CDP protocol 
datagrams between the DRC and the PFPs is shown below: 

35 

IP Message Transport Message Structure (DRC to PFP) 

[PFP ID#] + [DRC ID#] + [Message type] + [Next-Hop] + [IP Packet] 

(16 Bits) (8 Bits) (3 Bits) (raBits) (n Bytes) 

40 



45 



55 
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Control & Maintenance Message Structure (DRC to PFP) 
rPFP ID#] [DRC ID#1 + [Message type] + [CM Indicator] + [Function] + 
(16 Bits) (8 Bits) (8 Bits) (1 Bits) (15 Bits) 

[Arguments] 
(n Bytes) 

Routing Table App. Message Structure (DRC to PFP) 

[PFP ID#1 + [DRC ID#] + [Message type] + [Function] + [Arguments] 
(16 Bits) (8 Bits) (8 Bits) (8 Bits) (n Bytes) 

IP Message Transport Message Structure (PFP to DRC) 
[DRC- ID#1 + [Message type] + [Source PHYAT] + [IP Packet] 
(8 Bits) (8 Bits) (xBlts) (n Bytes) 

Control & Maintenance Message Structure (PFP to DRC) 

[DRC ID#] + [Source PFP ID#] + [Message type] + [C/M Indicator] + [Event] + 
(8 Bits) (16 Bits) (8 Bits) (1 Bits) (7 Bits) 

[Arguments] 
(n Bytes) 

Routing Table App. Message Structure (PFP to DRC) 
[DRC ID#] + [Source PFP JDtf] + [Message type] + [Event] + [Arguments] 
(8 Bits) (16 Bits) (8 Bits) (8 Bits) (n Bytes) 

The following are the assigned CDF message Types; 

Message Type OOH - CDP Link State Message 

Message Type 01 H - IPrAPI Message 

Message Type 02H - C&M-API Message 

Message Type 04H - R-APi Message 
[0046] CDP uses information within the API PDUsto detenninethe hostsystem'sSFIA for destination routing through 
the host systems transport media. DRC applications may have a need to multicast certain messages to multiple PFPs. 
Therefore, included are tables that allow multicasting to groups of IP addresses, groups of PFPs and groups of physical 
ports. Table identification required to perfomn the intra-system routing function is shown in FIG. 6. 
[0047] FiG. 7 illustrates message paths between Drivers 26 and 28 via the media 24. 

[0048] Whereas the present invention has been described with respect to specific embodiments thereof, it will be 
understood that various changes and modifications will be suggested to one skilled in the art and it is intended to 
encompass such changes and modifications as fall within the scope of the appended claims. 



Claims 



A protocol for a portable router f rameworic providing transportation of messages between a main processor having 
a protocol and packet flow processors having a protocol, the messages transported via a transport media, the 
protocol comprising: 

a Dynamic Routing and Control (DRC) driver including a plurality of Application Program Interfaces (API) for 
interfacing to the main processor; 

a transport interface for interfacing between said DRC driver APIs and the transport media; 
a Packet Flow Processor (PFP) driver including a plurality of Application Program Interfaces (API) for inter- 
facing to the packet flow processors; 
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a transport interface for interfacing between said PFP driver APIs and the transport media; and 

said DRC driver and said PFP driver transporting messages between the main processor and the packet flow 

processors. 

The protocol of Claim 1 wherein said messages transported between the main processor and the packet flow 
processors include internet protocol, routing table distribution and control and maintenance messages. 

The protocol of Claim 1 wherein said PFP driver transports traffic messages between ingress and egress ports of 
an PFP via the transport media. 

The protocol of Claim 3 wherein said traffic includes internet protocol and multi-protocol labels(MPLS) traffic. 

The protocol of Claim 1 wherein said DRC driver translates message fomnat and routing infomnatlon between the 
main proces;sor protocol and the transport media protocol. 

The protocol of Claim 1 wherein said DRC driver includes a routing table including addresses of the PFPs. 
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Control and distribution protocol for a portable router framework 



(57) A control and distribution protocol (CDP) is im- 
plemented for transport across a backplane bus, 
through a high-speed serial link or through a switching 
fabric connection. The protocol includes an intra-system 
transport of dynamic routing protocol (DRP) IP messag- 
es, the distribution of routing information within the rout- 
er, the transport of control and maintenance messages, 
and the transport of I P and mutti-protocol label switching 
(MPLS) traffic between ingress and egress ports. The 
protocol further includes a dynamic routing and control 



driver which interacts with dynamic routing control ap- 
plications to exchange messages that are to be trans- 
mitted to packet flow processors and to handoff mes- 
sages received from packet flow processors. A packet 
flow processor driver which services messages carried 
between the dynamic routing control and packet flow 
processors. An IP traffic interface provides transfer of 
IP L3/L2 protocol data unit (PDU) header primitive from 
the packet flow processors. Both the DRC driver and 
PFP driver include a framework transport interface. 



CO 
< 

o 

00 



PROCESSOR 
JSS 

TRWSPOflT 



ROUnNQ 
T«L£ APP. 



CONTTCJL t 
HUNTEmNCE 



COP/DRC 



COT/DRC 



DfUVER 



CDP/ORC 
GUI/ API 



SO 




FIG. 1 



/ 

eo 



PFP 



MXirXK 
TilBLE APP. 



COtfTML & 
MIHTEIMICe 



Q. 

LU 



Printed by Jouve, 7B001 PARIS FR) 



BLANK PAGE 




EP1 111 850 A3 



ANNEX TO THE EUROPEAN SEARCH REPORT 

ON EUROPEAN PATEKT APPUCAT10N NO. EP 00 12 2501 



THs arr>«x Wsn th» patonl Iwnlly members retaBng to the patent documents cfted In the ahowe-menHmiod EurDpean search report 

The rrwrrbers ar« as oorrtainMJ In the European Patent Ortce EDP fSo on 

T>» European Patent CWice Is In no way Irtbto 1« theee pwttoiart wWe*i are rne^ 

17-12-2001 



ctod ins 



H:t 

report 



Fut)licBt(on 
date 



Potwttlamilir 
member<s) 



PubilcHtion 
dste 



US 5802278 



01-09-1998 



US 
AU 
GB 
GB 
GB 
UO 
US 



5592622 A 
5736696 A 
2316843 A ,B 

2344498 A ,B 

2344499 A ,B 
9635988 Al 
5828835 A 



07-01-1997 
29-11-1996 
04-03-1998 
07-06-2000 
07-06-2000 
14-11-1996 
27-10-1998 



WO 0030294 



25-05-2000 AU 
WO 



2150500 A 
0030294 A2 



05-06-2000 
25-05-2000 



i 
e 



ra For more dei^ls about thte annex : »ee OffteialJoumal of the European Pattent Office, No, 12/82 



3 



This Page is Inserted by IFW Indexing and Scanning 
Operations and is not part of the Official Record 



Defective images within this document are accurate representations of the original 
documents submitted by the applicant. 

Defects in the images include but are not limited to the items checked: 

□ BLACK BORDERS 

□ IMAGE CUT OFF AT TOP, BOTTOM OR SIDES 



□ BLURRED OR ILLEGIBLE TEXT OR DRAWING 

□ SKEWED/SLANTED IMAGES 

□ COLOR OR BLACK AND WHITE PHOTOGRAPHS 

□ GRAY SCALE DOCUMENTS 

P^INES OR MARKS ON ORIGINAL DOCUMENT 

□ REFERENCE(S) OR EXHIBIT(S) SUBMITTED ARE POOR QUALITY 

□ OTHER: ' 

IMAGES ARE BEST AVAILABLE COPY. 
As rescanning these documents will not correct the image 
problems checked, please do not report these problems to 
the IFW Image Problem Mailbox. 



BEST AVAILABLE IMAGES 




FADED TEXT OR DRAWING 



